Looking at coolshop.dk as example, it would cause trouble if the webshop breaks down during a purchase of an item. For example if the backend of the website breaks down while purchasing such that to the user the item appears to have not been bought, but in reality the item has been bought. There is also the other way around, where the item appears to the user as bought, but the webshop has no record of this. To prevent this fault tolerance with 2 phase commit can be used. In this example we assume that coolshop.dk uses the MVC pattern for their website which gives it an architecture similar to that of \Cref{fig:2phasecommit}. 

\figur{1}{2phasecommit.png}{Overview of typical website architecture}{fig:2phasecommit}

Because the users is the initiator of a purchase, the protocol is hierarchical, meaning that the browser calls the webserver, which then calls the subsequent modules needed to be able to browse the website and perhaps perform a purchase.  

In this case, the frontend webserver acts as coordinator, and upon initiating a purchase, the server writes a "begin purchase" log entry. Next it sends a "prepare" request to the purchase module and a "prepare" request to the database. If they both responds with "yes", the web server knows that the purchase was successful, it sends "commit" messages to the payment module and the database. When the frontend server receives "acknowledge" messages from the payment module and the database it displays an order confirmation and writes an "end purchase" log entry. In this way the process of the purchase is ensured to be either successful or a failure and not half-half as in the examples above. If either the database or payment module reported an error, the coordinator (frontend webserver) would roll back the actions and display an error message to the user. 

The advantage of this approach is obviously that the webshop is more tolerant to faults: If a server breaks down during a purchase no order will be stuck in a half purchase state. The disadvantage is the added complexity to the webshop purchase phase because it needs to be ensured that each call is atomic. It does not make sense to roll back a successful request because another request, performed in parallel, failed. To combat the blocking behavior of the 2 phase commit protocol, the presumed abort behavior can be used, because this is a hierarchical solution. If the coordinator fails between the prepare and commit phase, the modules will normally be blocked because they will never receive any "commit" messages from the coordinator. With the presumed abort behavior, the subsequent modules will after some time assume that the coordinator aborted, and return to their initial state and be ready to receive a new "prepare" message. 